Hub and Node is a Selenium Grid architecture used to distribute Selenium WebDriver test execution across one or more machines. The Hub acts as the central entry point for test requests, while Nodes provide the browsers and computing resources where the actual WebDriver sessions run.
Hub and Node architecture is especially useful when organizations need to execute Selenium tests across multiple browsers, operating systems, browser versions, and machines. It also supports scaling test execution by adding additional Nodes.
In modern Selenium Grid, the Hub is responsible for coordinating Grid components and routing new session requests, while Nodes manage browser sessions and execute commands received from the Grid. Selenium's current documentation describes Hub and Node as one of the Grid deployment modes, alongside Standalone and Distributed modes. :contentReference[oaicite:0]{index=0}
Course Resource: Selenium Training | Register for Course Demo
Selenium Grid is a Selenium infrastructure that allows WebDriver tests to execute on remote machines and different browser environments. It is commonly used for parallel execution, cross-browser testing, cross-platform testing, and distributed automation.
Instead of running every Selenium test on the same local computer, Grid can route WebDriver session requests to available remote Nodes.
Test Script
|
v
Selenium Grid
|
v
Hub / Router / Distributor
|
+------------------+
| |
v v
Node 1 Node 2
Chrome Firefox
Windows Linux
| |
v v
Browser Session Browser Session
Selenium Grid is designed to make parallel execution across multiple machines and different browser environments possible. :contentReference[oaicite:1]{index=1}
A Hub is the central coordination point in a Hub-and-Node Selenium Grid deployment. Test clients send WebDriver session requests to the Grid endpoint, and the Grid determines where those sessions should run.
In the current Selenium Grid architecture, a Hub contains several Grid components such as the Router, Distributor, Session Map, New Session Queue, and Event Bus. :contentReference[oaicite:2]{index=2}
The Hub provides a central entry point so that test machines do not need to communicate independently with every browser machine.
A Node is a machine or execution environment that provides browser sessions for Selenium Grid. A Node manages available browser slots and executes WebDriver commands for sessions assigned to it.
A Grid can contain multiple Nodes, and Nodes can have different operating systems and browser configurations. For example, one Node may provide Chrome on Windows while another provides Firefox on Linux. :contentReference[oaicite:3]{index=3}
Node 1
Windows
Chrome
Edge
Node 2
Linux
Firefox
Chrome
Node 3
macOS
Safari
Chrome
| Feature | Hub | Node |
|---|---|---|
| Primary Role | Coordinates and routes Grid requests | Runs browser sessions |
| Location | Central Grid endpoint | Execution machine/environment |
| Receives Test Requests | Yes | Receives sessions assigned by Grid |
| Runs Browser | Not normally | Yes |
| Number | One Hub in a Hub-and-Node deployment | One or more Nodes |
| Main Responsibility | Routing, distribution, and coordination | Browser/session execution |
| Scaling | Central coordination component | Add Nodes to increase execution capacity |
The basic Hub and Node architecture can be represented as follows:
Selenium Test
|
v
RemoteWebDriver
|
v
Selenium Grid Hub
|
+----------+----------+
| |
v v
Node 1 Node 2
Chrome Firefox
Windows Linux
| |
v v
Browser Session Browser Session
The test sends a session request to the Grid. The Grid then identifies an available Node whose capabilities match the requested browser and other capabilities.
Hub and Node architecture is important because modern automation projects frequently need to test applications in multiple browser and operating-system combinations.
The Hub and Nodes communicate through Selenium Grid's internal communication mechanisms. In the current Grid architecture, Nodes register with the Distributor through the Event Bus and provide information about their status and capabilities. :contentReference[oaicite:4]{index=4}
Node Starts
|
v
Node Registration
|
v
Event Bus
|
v
Distributor
|
v
Grid Knows Node Status
|
v
Node Available for Sessions
With current Selenium Server versions, a Hub can be started using the Selenium Server JAR and the hub role.
java -jar selenium-server-<version>.jar hubBy default, the Hub listens for Grid requests on port 4444. :contentReference[oaicite:5]{index=5}
A Node can be started using the Selenium Server JAR and the node role.
java -jar selenium-server-<version>.jar nodeWhen started, the Node can detect available browser drivers from the system environment and register with the Grid. :contentReference[oaicite:6]{index=6}
For learning and basic testing, the Hub and Node can be started on the same machine.
Start the Hub:
java -jar selenium-server-<version>.jar hubThen start the Node:
java -jar selenium-server-<version>.jar nodeThe current Selenium documentation provides this as a basic Hub-and-Node setup. :contentReference[oaicite:7]{index=7}
In a real automation environment, the Hub and Nodes can run on different machines. This allows the Grid to use different operating systems and browser installations.
Machine 1
|
+-- Selenium Hub
|
+-- Port 4444
Machine 2
|
+-- Selenium Node
+-- Chrome
+-- Windows
Machine 3
|
+-- Selenium Node
+-- Firefox
+-- Linux
The Node can be configured with the Hub address when the Hub and Node are running on different machines. :contentReference[oaicite:8]{index=8}
When the Hub and Node are separate, the Node needs to know where the Hub/Grid endpoint is located.
java -jar selenium-server-<version>.jar node --hub http://<hub-ip>:4444The exact network configuration depends on how the Grid is deployed. Selenium's current documentation notes that Hub and Nodes communicate through HTTP and the Event Bus during registration. :contentReference[oaicite:9]{index=9}
The default Grid endpoint for a Hub is:
http://localhost:4444Tests using RemoteWebDriver can send session requests to this Grid endpoint.
A Node commonly uses port 5555 by default, although the port can be customized.
For example, a Node can be started on another port:
java -jar selenium-server-<version>.jar node --port 5555Multiple Nodes on the same machine can use different ports.
Multiple Node processes can be configured on a machine using different ports and appropriate capabilities.
Node 1
java -jar selenium-server-<version>.jar node --port 5555
Node 2
java -jar selenium-server-<version>.jar node --port 6666
Selenium's documentation provides multiple-Node examples using separate ports. :contentReference[oaicite:10]{index=10}
One of the major uses of Hub and Node architecture is cross-browser testing.
Selenium Test
|
v
Grid
|
+------------+------------+
| | |
v v v
Chrome Firefox Edge
Node Node Node
| | |
v v v
Browser Browser Browser
A test can request a specific browser capability, and the Grid can route the session to a suitable Node.
Nodes do not necessarily need to use the same operating system. A Grid can combine machines with Windows, Linux, or macOS environments when the required browsers and capabilities are available.
| Node | Operating System | Browser |
|---|---|---|
| Node 1 | Windows | Chrome |
| Node 2 | Linux | Firefox |
| Node 3 | macOS | Safari |
| Node 4 | Windows | Edge |
This allows the same Selenium test suite to be validated across multiple environments.
RemoteWebDriver is used by Selenium clients when the browser session needs to be created remotely through a Grid.
import java.net.URL;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
public class GridTest {
public static void main(String[] args) throws Exception {
ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
new URL("http://localhost:4444"),
options
);
driver.get("https://example.com");
System.out.println(driver.getTitle());
driver.quit();
}
}
The Grid receives the new-session request and routes it to a suitable Node.
RemoteWebDriver is a Selenium WebDriver implementation used to communicate with a remote WebDriver server or Selenium Grid.
Instead of creating a browser directly on the local machine:
WebDriver driver = new ChromeDriver();a remote test can use:
WebDriver driver = new RemoteWebDriver(
new URL("http://localhost:4444"),
options
);
| Feature | Local WebDriver | RemoteWebDriver |
|---|---|---|
| Execution | Usually local | Remote/Grid environment |
| Multiple Machines | Limited | Supported |
| Cross-Browser Grid | Not the primary purpose | Supported |
| Grid Integration | Not required | Commonly used |
| Parallel Scaling | Limited to local resources | Can scale across Nodes |
Capabilities describe the browser and environment requirements of a requested session. The Grid uses the requested capabilities when determining which available Node can handle the session.
For example, a Chrome session can be created using:
ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
new URL("http://localhost:4444"),
options
);
Modern Selenium uses browser-specific Options classes to configure browser capabilities.
A Node can provide one or more browser configurations. During startup, Selenium can detect available browser drivers and create browser slots based on the Node configuration. :contentReference[oaicite:11]{index=11}
For example:
Node
|
+-- Chrome
|
+-- Firefox
|
+-- Edge
The actual browser availability depends on the machine and Node configuration.
The session creation process can be represented as:
Test Code
|
v
RemoteWebDriver
|
v
Grid Endpoint
|
v
Router
|
v
New Session Queue
|
v
Distributor
|
v
Matching Node
|
v
Browser Session
|
v
Session Created
In Selenium Grid's current architecture, the Router handles requests, the New Session Queue manages pending session requests, and the Distributor assigns matching sessions to Nodes. :contentReference[oaicite:12]{index=12}
The Distributor is a Grid component responsible for matching new session requests with suitable Node slots.
It considers the requested capabilities and available Node information when assigning sessions.
New Session Request
|
v
New Session Queue
|
v
Distributor
|
Capability Match
|
v
Available Node
|
v
Browser Session
The Router is the Grid component that acts as an entry point for WebDriver requests and routes requests to the appropriate internal Grid component.
For new sessions, the request is routed toward the session queue and distribution process. For an existing session, the Router directs commands toward the component responsible for the active session.
The Event Bus provides an internal communication mechanism between Grid components. In a distributed Grid, it supports communication among components such as Nodes, Distributor, New Session Queue, and Session Map. :contentReference[oaicite:13]{index=13}
Node
|
+--------+
|
v
Event Bus
|
+------+------+
| |
v v
Distributor Other Grid Components
When a Node starts, it registers its availability and configuration with the Grid. Selenium Grid's architecture uses heartbeat events and status information to maintain knowledge of Node state. :contentReference[oaicite:14]{index=14}
Node Starts
|
v
Heartbeat / Registration
|
v
Distributor
|
v
Node Status Checked
|
v
Node Available
A Node can have different availability states. Current Selenium Grid architecture documents states such as up, draining, and down. A draining Node does not receive new sessions while existing sessions are allowed to finish. :contentReference[oaicite:15]{index=15}
| Status | Meaning |
|---|---|
| UP | Node is available for new work |
| DRAINING | Node is finishing existing sessions and should not receive new sessions |
| DOWN | Node is unavailable |
Hub and Node architecture can support parallel execution by distributing independent sessions across available Node slots.
Test 1 ----\
Test 2 -----+----> Grid ----> Node 1 ----> Chrome
Test 3 -----+----> Grid ----> Node 2 ----> Firefox
Test 4 ----/ \--> Node 3 ----> Edge
The amount of parallel execution depends on the number of available Node slots, machine resources, test design, and Grid configuration.
TestNG Data Providers can be combined with Selenium Grid to execute the same test with multiple data sets and remote browser sessions.
@DataProvider(name = "browsers")
public Object[][] browsers() {
return new Object[][] {
{"chrome"},
{"firefox"},
{"edge"}
};
}
@Test(dataProvider = "browsers")
public void browserTest(String browser) {
// Browser-specific Grid setup
}
The test framework can map the browser value to an appropriate browser Options object and create a RemoteWebDriver session.
TestNG can control test execution while Selenium Grid handles remote browser execution.
TestNG
|
+-- Test 1
|
+-- Test 2
|
+-- Test 3
|
v
RemoteWebDriver
|
v
Selenium Grid
|
+-- Node 1
+-- Node 2
+-- Node 3
This separation allows the test framework and browser infrastructure to perform different responsibilities.
Hub and Node architecture can be combined with the Page Object Model (POM). The Page Object manages application interaction while the Grid manages browser execution.
Test Class
|
v
Page Object
|
v
RemoteWebDriver
|
v
Selenium Grid
|
v
Node
|
v
Browser
Maven can be used to build and execute Selenium TestNG projects that connect to Selenium Grid.
mvn clean testA typical execution flow is:
Maven
|
v
TestNG
|
v
Selenium Test
|
v
RemoteWebDriver
|
v
Grid
|
v
Node
|
v
Browser
Selenium Grid can be integrated with CI/CD systems so automated tests can run on remote browser infrastructure.
Developer Commit
|
v
CI/CD Pipeline
|
v
Build
|
v
TestNG
|
v
RemoteWebDriver
|
v
Selenium Grid
|
+----> Node 1
+----> Node 2
+----> Node 3
|
v
Test Report
Selenium's documentation also lists CI/CD tools such as GitHub Actions and Jenkins as possible environments for running Grid-based automation. :contentReference[oaicite:16]{index=16}
A common real-world requirement is to verify the same application on multiple browsers.
| Test | Browser | Node |
|---|---|---|
| Login | Chrome | Node 1 |
| Login | Firefox | Node 2 |
| Login | Edge | Node 3 |
| Checkout | Chrome | Node 1 |
| Checkout | Firefox | Node 2 |
Hub and Node architecture is useful when the automation team needs to test applications on different operating systems.
Selenium Grid
|
+-------------+-------------+
| | |
v v v
Windows Linux macOS
| | |
Chrome Firefox Safari
| | |
Node 1 Node 2 Node 3
Each Node can provide the environment and browsers available on its machine.
Testing different browser versions can be useful when application compatibility must be validated across supported environments. The exact browser/version combinations depend on the Node configuration and available infrastructure.
Node 1 -> Chrome Version A
Node 2 -> Chrome Version B
Node 3 -> Firefox Version A
Node 4 -> Edge Version A
One advantage of Hub and Node architecture is that additional Nodes can be added to increase available execution capacity.
Before Scaling
Hub
|
+-- Node 1
+-- Node 2
After Scaling
Hub
|
+-- Node 1
+-- Node 2
+-- Node 3
+-- Node 4
+-- Node 5
Selenium documentation describes Hub and Node as a way to scale capacity up or down without tearing down the entire Grid. :contentReference[oaicite:17]{index=17}
A Node provides slots representing available browser-session capacity. The exact number of slots depends on the Node's configuration and available resources.
Node
|
+-- Slot 1 -> Chrome
+-- Slot 2 -> Chrome
+-- Slot 3 -> Firefox
+-- Slot 4 -> Edge
When sessions are running, available slots become occupied until those sessions finish.
Nodes can be configured using command-line options. Selenium provides options for settings such as ports, maximum sessions, browser implementations, driver detection, and other Node behavior. :contentReference[oaicite:18]{index=18}
For example:
java -jar selenium-server-<version>.jar node \
--max-sessions 4 \
--port 7777
Configuration should be designed according to the resources and workload of the execution machine.
A Node can be configured with a maximum number of concurrent sessions. This can help prevent a machine from being overloaded.
java -jar selenium-server-<version>.jar node \
--max-sessions 4
The appropriate value depends on CPU, memory, browser workload, test behavior, and environment capacity.
A Node can be configured to expose selected browser implementations instead of automatically using every available browser driver.
java -jar selenium-server-<version>.jar node \
--driver-implementation "firefox" \
--driver-implementation "edge"
Selenium's current Grid CLI documentation provides Node configuration examples using browser-specific driver implementations. :contentReference[oaicite:19]{index=19}
A Node can run on a separate machine from the Hub.
Machine A
+----------------------+
| Selenium Hub |
| Port 4444 |
+----------------------+
|
| Network
|
v
Machine B
+----------------------+
| Selenium Node |
| Chrome / Firefox |
+----------------------+
Network connectivity and appropriate firewall rules are necessary for the Grid components to communicate successfully.
In a distributed environment, the Hub and Nodes need network connectivity. Selenium documentation notes that Hub and Node communication involves HTTP and Event Bus communication, including the Event Bus ports used for registration in the documented default configuration. :contentReference[oaicite:20]{index=20}
When configuring a real environment, verify:
After starting a Grid, the Grid interface can be accessed through its configured URL. With the default Hub/Grid endpoint, the common address is:
http://localhost:4444The Grid interface can be useful for checking the Grid status and available infrastructure.
Selenium Grid supports different deployment modes. Standalone combines Grid components into a single process and is convenient for simple setups, while Hub and Node separates coordination and browser execution across components/machines. :contentReference[oaicite:21]{index=21}
| Feature | Standalone | Hub and Node |
|---|---|---|
| Setup | Simple | More infrastructure |
| Machines | Single machine | Can use multiple machines |
| Central Hub | No separate Hub role | Yes |
| Scaling | Limited to one machine | Can add Nodes |
| Cross-Platform | Limited | Supported across Nodes |
| Use Case | Local/simple Grid | Distributed browser execution |
In Hub and Node mode, the Hub groups several Grid components into the central coordination layer. In Distributed mode, Grid components can be deployed separately, which provides greater infrastructure flexibility. :contentReference[oaicite:22]{index=22}
| Feature | Hub and Node | Distributed |
|---|---|---|
| Deployment | Hub plus Nodes | Individual Grid components |
| Complexity | Moderate | Higher |
| Scalability | Good | Highly configurable |
| Typical Use | Multi-machine browser execution | Large/custom Grid infrastructure |
Hub and Node environments can also be deployed using containers. Containerized Nodes can make browser environments easier to reproduce and manage.
Docker Environment
|
+-- Hub Container
|
+-- Chrome Node
|
+-- Firefox Node
|
+-- Edge Node
The exact container configuration depends on the Selenium Grid deployment approach and infrastructure.
Nodes can run on cloud or virtual machines instead of physical computers. This can allow teams to create additional browser execution capacity when required.
Cloud Infrastructure
|
+-- Hub
|
+-- Node 1
|
+-- Node 2
|
+-- Node 3
|
+-- Node 4
The same basic architecture applies regardless of whether the machines are physical, virtual, or containerized.
Jenkins can trigger Selenium tests that use RemoteWebDriver and Selenium Grid.
Jenkins
|
v
Maven
|
v
TestNG
|
v
RemoteWebDriver
|
v
Selenium Grid Hub
|
+---- Node 1
+---- Node 2
+---- Node 3
|
v
Test Results
1. Test execution starts
|
v
2. Test creates RemoteWebDriver
|
v
3. Session request reaches Grid
|
v
4. Grid checks requested capabilities
|
v
5. Distributor finds suitable Node
|
v
6. Session is created on Node
|
v
7. Browser starts
|
v
8. Selenium commands execute
|
v
9. Test completes
|
v
10. Browser session is closed
|
v
11. Node slot becomes available
If a Node becomes unavailable, new session requests should not be assigned to that unavailable capacity. Grid architecture continuously maintains Node status information and uses status checks to maintain an accurate view of the Grid. :contentReference[oaicite:23]{index=23}
Common causes of Node failure include:
| Problem | Possible Cause |
|---|---|
| Node not visible | Registration or network problem |
| Session cannot start | No matching browser capability |
| Connection refused | Wrong host/port or service not running |
| Browser fails to launch | Browser/driver configuration issue |
| Tests are slow | Insufficient Node resources or overloaded infrastructure |
| Parallel tests interfere | Shared WebDriver or unsafe test data |
| Node becomes unavailable | Machine, network, or Selenium process failure |
Current Selenium Grid documentation notes that Nodes can detect browser drivers available through the system PATH, and Selenium Manager can also be used to configure drivers when enabled. :contentReference[oaicite:24]{index=24}
This means browser-driver management should be considered when preparing a Node machine.
Selenium Grid infrastructure should not be exposed publicly without appropriate security controls. Selenium's official documentation specifically warns that an unprotected Grid can expose internal infrastructure and allow unauthorized parties to interact with Grid resources. :contentReference[oaicite:25]{index=25}
Important security practices include:
selenium-grid-project
|
|-- pom.xml
|
|-- src
| |-- test
| |-- java
| |-- tests
| | |-- LoginTest.java
| | |-- SearchTest.java
| | |-- CheckoutTest.java
| |
| |-- pages
| | |-- LoginPage.java
| | |-- SearchPage.java
| | |-- CheckoutPage.java
| |
| |-- utilities
| |-- DriverFactory.java
| |-- ConfigReader.java
| |-- TestDataProvider.java
|
|-- testng.xml
|
|-- reports
A Driver Factory can centralize browser creation and Grid configuration.
import java.net.URL;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.firefox.FirefoxOptions;
public class DriverFactory {
public static WebDriver createDriver(String browser) throws Exception {
if (browser.equalsIgnoreCase("chrome")) {
ChromeOptions options = new ChromeOptions();
return new RemoteWebDriver(
new URL("http://localhost:4444"),
options
);
}
if (browser.equalsIgnoreCase("firefox")) {
FirefoxOptions options = new FirefoxOptions();
return new RemoteWebDriver(
new URL("http://localhost:4444"),
options
);
}
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
import org.openqa.selenium.WebDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class GridTest {
WebDriver driver;
@DataProvider(name = "browsers")
public Object[][] browsers() {
return new Object[][] {
{"chrome"},
{"firefox"}
};
}
@Test(dataProvider = "browsers")
public void testApplication(String browser) throws Exception {
driver = DriverFactory.createDriver(browser);
driver.get("https://example.com");
System.out.println(
"Running on: " + browser
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
Consider an e-commerce application that must be tested on Chrome, Firefox, and Edge.
TestNG Suite
|
v
Selenium Grid
|
+------------+------------+
| | |
v v v
Node 1 Node 2 Node 3
Chrome Firefox Edge
| | |
v v v
Login Login Login
Search Search Search
Cart Cart Cart
Checkout Checkout Checkout
The same business workflow can be executed against multiple browser environments without maintaining separate automation projects for each browser.
Parallel execution can significantly reduce overall suite duration when enough independent Node capacity is available.
Test A ---> Node 1 ---> Chrome
Test B ---> Node 2 ---> Firefox
Test C ---> Node 3 ---> Edge
Test D ---> Node 4 ---> Chrome
However, parallel execution should be designed carefully. Test data, WebDriver instances, application state, and external resources should be isolated where required.
| Aspect | Local Execution | Hub and Node |
|---|---|---|
| Browser Location | Local machine | Node machine |
| Remote Execution | No | Yes |
| Multiple Machines | Not normally | Yes |
| Cross-Platform | Limited | Supported through Nodes |
| Scaling | Limited | Can add Nodes |
| Infrastructure | Simple | More complex |
| Purpose | Command |
|---|---|
| Start Hub | java -jar selenium-server-<version>.jar hub |
| Start Node | java -jar selenium-server-<version>.jar node |
| Start Node on custom port | java -jar selenium-server-<version>.jar node --port 5555 |
| Start Node with Hub address | java -jar selenium-server-<version>.jar node --hub http://<hub-ip>:4444 |
| Limit sessions | java -jar selenium-server-<version>.jar node --max-sessions 4 |
| Show Hub help | java -jar selenium-server-<version>.jar hub --help |
| Show Node help | java -jar selenium-server-<version>.jar node --help |
The exact command-line options depend on the Selenium Server version; Selenium provides component-specific configuration help through the --help options and the Grid configuration help commands. :contentReference[oaicite:26]{index=26}
Selenium Grid is an infrastructure for executing Selenium WebDriver sessions remotely and across multiple environments.
A Hub is the central coordination layer in a Hub-and-Node Grid deployment that receives and routes WebDriver session requests.
A Node is an execution environment that provides browser sessions and runs WebDriver commands.
It allows remote, cross-browser, cross-platform, and scalable WebDriver execution across multiple machines.
Yes. Hub and Nodes can communicate over a network.
Yes. A Grid can contain multiple Nodes.
RemoteWebDriver is used by Selenium clients to create and control browser sessions on remote WebDriver infrastructure such as Selenium Grid.
The default Grid endpoint commonly uses port 4444.
A Node provides browser execution capacity and manages browser sessions assigned to it.
The Distributor matches new session requests with appropriate available Node slots.
The Router provides an entry point for WebDriver requests and routes them to the appropriate Grid component.
The Event Bus is an internal communication mechanism used by Grid components.
Yes. Independent sessions can be distributed across available Node capacity.
Yes. Different Nodes can run different operating systems and browser configurations.
Yes, depending on its browser installations and configuration.
The session request cannot be assigned until suitable capacity becomes available or the request fails according to the Grid and test configuration.
Yes. TestNG can manage test execution while RemoteWebDriver connects tests to the Grid.
Yes. POM manages application interaction while Grid manages remote browser execution.
Yes. Selenium Grid can be integrated into CI/CD pipelines.
Adding suitable Nodes can increase available browser execution capacity and support more concurrent sessions.
| Concept | Description |
|---|---|
| Selenium Grid | Infrastructure for remote and distributed WebDriver execution |
| Hub | Central coordination and routing layer in Hub-and-Node mode |
| Node | Machine/environment that runs browser sessions |
| RemoteWebDriver | Client used to create remote WebDriver sessions |
| Distributor | Matches session requests with available Node slots |
| Router | Routes incoming WebDriver requests |
| Event Bus | Internal communication mechanism between Grid components |
| Port 4444 | Default Grid endpoint in common Selenium Grid configurations |
| Node Port | Common default Node port is 5555, but it can be configured |
| Cross-Browser | Testing across different browser types |
| Cross-Platform | Testing across different operating systems |
| Parallel Execution | Running independent sessions concurrently |
CI/CD Server
|
v
TestNG Suite
|
v
RemoteWebDriver
|
v
Selenium Grid Hub
|
+----------+----------+
| | |
v v v
Node 1 Node 2 Node 3
Windows Linux macOS
Chrome Firefox Safari
| | |
v v v
Browser Browser Browser
| | |
+----------+----------+
|
v
Test Results
Hub and Node is an important Selenium Grid architecture for distributed WebDriver execution. The Hub provides the central coordination and routing layer, while Nodes provide the machines and browser sessions where tests actually execute.
Hub and Node architecture is useful for cross-browser testing, cross-platform testing, parallel execution, remote execution, and scalable Selenium automation. A Grid can contain multiple Nodes with different operating systems, browsers, and configurations.
Modern Selenium Grid also includes internal components such as the Router, Distributor, New Session Queue, Session Map, and Event Bus. The Distributor matches session requests with available Node capacity, while Nodes execute the browser sessions. :contentReference[oaicite:27]{index=27}
For professional automation frameworks, Hub and Node can be combined with TestNG, Data Providers, Page Object Model, Maven, CI/CD pipelines, reusable Driver Factories, parallel execution, and reporting systems.
Final Takeaway: The Hub coordinates the Grid and the Nodes provide browser execution capacity. Together, they allow Selenium WebDriver tests to run remotely across different browsers, operating systems, and machines.
Learn more about Selenium automation and related testing concepts:
